<div class="tmd-doc">
<h1 class="tmd-header-1">
Go FAQ 101
</h1>
<p></p>
<div class="tmd-usual">
<span class="tmd-italic">(This is an unofficial Go FAQ. The official one is </span><a href="https://golang.org/doc/faq"><span class="tmd-italic">here</span></a><span class="tmd-italic">.)</span>
</div>
<p></p>
<p></p>
<div class="tmd-usual">
Index:
</div>
<p></p>
<ul id="unofficial-faq.html" class="tmd-list summaries">
<li class="tmd-list-item">
<div class="tmd-usual">
compiler and runtime
</div>
<ul class="tmd-list index">
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#error-non-name">What does the compile error message <code class="tmd-code-span">non-name **	- on left side of :=</code> mean?</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#error-missing-left-brace">What does the compile error message <code class="tmd-code-span">unexpected newline, expecting { after if clause</code> mean?</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#error-declared-not-used">What does the compiler error message <code class="tmd-code-span">declared and not used</code> mean?</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#map-iteration-order">Does Go runtime maintain the iteration orders for maps?</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#compiler-field-padding">Will Go compilers do padding to ensure field alignments for struct types?</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#final-zero-size-field">Why does the final field of a zero-sized type in a struct contribute to the size of the struct sometimes?</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#new-function">Is <code class="tmd-code-span">new(T)</code> a sugar of <code class="tmd-code-span">var t T; (&amp;t)</code>?</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#fatal-error-deadlock">What does the runtime error message <code class="tmd-code-span">all goroutines are asleep - deadlock</code> mean?</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#_64-bit-alignment">Are 64-bit integer values guaranteed to be 64-bit aligned so that they can be accessed atomically?</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#atomical-assignment">Are assignments of values atomic operations?</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#zero-values-zero-bytes">Is every zero value composed of a sequence of zero bytes in memory?</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#function-inline">Does the standard Go compiler support function inlining?</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#finalizers">Can I use finalizers as object destructors?</a>
</div>
</li>
</ul>
<p></p>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
standard packages
</div>
<ul class="tmd-list index">
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#get-days-of-month">How to get the number of days of any month by using as few code lines as possible?</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#time-sleep-after">What is the difference between the function call <code class="tmd-code-span">time.Sleep(d)</code> and the channel receive operation <code class="tmd-code-span">&lt;-time.After(d)</code>?</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#trim">Calls of the <code class="tmd-code-span">TrimLeft</code> and <code class="tmd-code-span">TrimRight</code> functions in the <code class="tmd-code-span">strings</code> and <code class="tmd-code-span">bytes</code> standard packages often return unexpected results, are there bugs in these function implementations?</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#fmt-print-println">What are the differences between the <code class="tmd-code-span">fmt.Print</code> and <code class="tmd-code-span">fmt.Println</code> functions?</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#log-print-println">Is there any difference between the <code class="tmd-code-span">log.Print</code> and <code class="tmd-code-span">log.Println</code> functions?</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#fmt-print-synced">Are <code class="tmd-code-span">fmt.Print</code>, <code class="tmd-code-span">fmt.Println</code> and <code class="tmd-code-span">fmt.Printf</code> functions synchronized?</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#print-builtin-fmt-log">What are the differences between the built-in <code class="tmd-code-span">print</code>/<code class="tmd-code-span">println</code> functions and the corresponding print functions in the <code class="tmd-code-span">fmt</code> and <code class="tmd-code-span">log</code> standard packages?</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#math-crypto-rand">What is the difference between the random numbers produced by the <code class="tmd-code-span">math/rand</code> standard package and the <code class="tmd-code-span">crypto/rand</code> standard package?</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#math-round">Why isn't there a <code class="tmd-code-span">math.Round</code> function?</a>
</div>
</li>
</ul>
<p></p>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
type system
</div>
<ul class="tmd-list index">
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#incomparable-types">Which types don't support comparisons?</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#nil-equality">Why aren't two <code class="tmd-code-span">nil</code> values equal sometimes?</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#slice-conversion">Why don't type <code class="tmd-code-span">[]T1</code> and <code class="tmd-code-span">[]T2</code> share the same underlying type even if the two different types <code class="tmd-code-span">T1</code> and <code class="tmd-code-span">T2</code> share the same underlying type?</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#unaddressable-values">Which values can and which values can't have their addresses taken?</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#map-elements-are-unaddressable">Why are map elements not addressable?</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#slice-elements-always-addressable">Why elements of a non-nil slice are always addressable, even if the slice is unaddressable?</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#method-set-relation">For any non-pointer non-interface type <code class="tmd-code-span">T</code>, why is the method set of <code class="tmd-code-span">*T</code> always a super set of the method set of <code class="tmd-code-span">T</code>, but not vice versa?</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#types-can-have-methods">Which types can we implement methods for?</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#declare-immutables">How to declare immutable values in Go?</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#set-container-type">Why isn't there a built-in <code class="tmd-code-span">set</code> container type?</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#byte-rune-slice-string">What is byte? What is rune? How to convert <code class="tmd-code-span">[]byte</code> and <code class="tmd-code-span">[]rune</code> values to strings?</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#pointer-atomic">How to manipulate pointer values atomically?</a>
</div>
</li>
</ul>
<p></p>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
others
</div>
<ul class="tmd-list index">
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#about-iota">What does <code class="tmd-code-span">iota</code> mean?</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#check-if-channels-closed">Why isn't there a built-in <code class="tmd-code-span">closed</code> function to check whether or not a channel is closed?</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#return-local-pointers">Is it safe for a function to return pointers of local variables?</a>
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="#gopher">What does the word <span class="tmd-bold"><span class="tmd-italic">gopher</span></span> mean in Go community?</a>
</div>
</li>
</ul>
</li>
</ul>
<p></p>
<div class="tmd-base summaries-items">
<p></p>
<div class="tmd-usual">
<span class="tmd-italic">compiler and runtime</span>
</div>
<p></p>
<h3 id="error-non-name" class="tmd-header-3">
What does the compile error message <code class="tmd-code-span">non-name *** on left side of :=</code> mean?
</h3>
<p></p>
<div class="tmd-usual">
Up to now (Go 1.25), there is <a href="https://golang.org/ref/spec#Short_variable_declarations">a mandatory rule</a> for short variable declarations:
</div>
<div class="tmd-base alert alert-success">
<div class="tmd-usual">
All items at the left side of <code class="tmd-code-span">:=</code> must be pure <a href="https://golang.org/ref/spec#Identifiers">identifiers</a> and at least one of them must be a new variable name.
</div>
</div>
<p></p>
<p></p>
<div class="tmd-usual">
This means container elements (<code class="tmd-code-span">x[i]</code>), struct fields (<code class="tmd-code-span">x.f</code>), pointer dereferences (<code class="tmd-code-span">*p</code>) and qualified identifiers (<code class="tmd-code-span">aPackage.Value</code>) can't appear at the left side of <code class="tmd-code-span">:=</code>.
</div>
<p></p>
<div class="tmd-usual">
Currently, there is an <a href="https://github.com/golang/go/issues/377">open issue</a> (which was merged with <a href="https://github.com/golang/go/issues/6842">a more related one</a>) for this problem. It looks Go core team wants to <a href="https://github.com/golang/go/issues/30318">leave this problem unresolved currently</a>.
</div>
<p></p>
<p></p>
<h3 id="error-missing-left-brace" class="tmd-header-3">
What does the compile error message <code class="tmd-code-span">unexpected newline, expecting { ...</code> mean?
</h3>
<p></p>
<div class="tmd-usual">
In Go, we can't break a code line at an arbitrary position. Please read <a href="line-break-rules.html">line break rules in Go</a> for details. By the rules, generally, it is not okay to break code lines just before the open brackets.
</div>
<p></p>
<p></p>
<div class="tmd-usual">
For example, the following code
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">if true
{
}

for i := 0; i &lt; 10; i++
{
}

var _ = []int
{
	1, 2, 3
}
</code></pre>
<p></p>
<div class="tmd-usual">
will be interpreted as
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">if true;
{
}

for i := 0; i &lt; 10; i++;
{
}

var _ = []int;
{
	1, 2, 3;
}
</code></pre>
<p></p>
<div class="tmd-usual">
Go compilers will report an error for each open bracket <code class="tmd-code-span">{</code>. To avoid these errors, we should rewrite the above code as the following.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">if true {
}

for i := 0; i &lt; 10; i++ {
}

var _ = []int {
	1, 2, 3,
}
</code></pre>
<p></p>
<h3 id="error-declared-not-used" class="tmd-header-3">
What does the compiler error message <code class="tmd-code-span">declared and not used</code> mean?
</h3>
<p></p>
<div class="tmd-usual">
For the standard Go compiler, each variable declared in local code blocks must be used as a r-value (right-hand-side value) for at least once.
</div>
<p></p>
<div class="tmd-usual">
So the following code fails to compile.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">func f(x bool) {
	var y = 1 // y declared but not used (as r-values)
	if x {
		y = 2 // here y is used as a left-hand-side value
	}
}
</code></pre>
<p></p>
<p></p>
<h3 id="map-iteration-order" class="tmd-header-3">
Does Go runtime maintain the iteration orders for maps?
</h3>
<p></p>
<div class="tmd-usual">
No. <a href="https://golang.org/ref/spec#For_range">Go 1 specification</a> says the iteration order over a map is not specified and is not guaranteed to be the same from one iteration to the next. For the standard Go compiler, the map iteration orders are always partially randomized to varying extent. If you require a stable iteration order for a map you must maintain the order by yourself. Please read <a href="https://go.dev/blog/maps#iteration-order">Go maps in action</a> for more information.
</div>
<p></p>
<p></p>
<div class="tmd-usual">
However, please note, since Go 1.12, the entry order in the print result of the print functions in standard packages are always ordered.
</div>
<p></p>
<h3 id="compiler-field-padding" class="tmd-header-3">
Will Go compilers do padding to ensure field alignments for struct types?
</h3>
<p></p>
<div class="tmd-usual">
At least for the standard Go compiler and gccgo, the answer is yes. How many bytes will be padded is OS and compiler dependent. Please read <a href="memory-layout.html#size-and-padding">memory layouts</a> for details.
</div>
<p></p>
<p></p>
<p></p>
<div class="tmd-usual">
Go Compilers will not rearrange struct fields to minimize struct value sizes. Doing this may cause some unexpected results. However, programmers can minimize padding by reordering the fields manually.
</div>
<p></p>
<h3 id="final-zero-size-field" class="tmd-header-3">
Why does the final field of a zero-sized type in a struct contribute to the size of the struct sometimes?
</h3>
<p></p>
<p></p>
<div class="tmd-usual">
In the current standard Go runtime implementation, as long as a memory block is referenced by at least one active pointer, that memory block will not be viewed as garbage and will not be collected.
</div>
<p></p>
<div class="tmd-usual">
All the fields of an addressable struct value can be taken addresses. If the size of the final field in a non-zero-sized struct value is zero, then taking the address of the final field in the struct value will return an address which is beyond the allocated memory block for the struct value. The returned address may point to another allocated memory block which closely follows the one allocated for the non-zero-sized struct value. As long as the returned address is stored in an active pointer value, the other allocated memory block will not get garbage collected, which may cause memory leaking.
</div>
<p></p>
<div class="tmd-usual">
To avoid these kinds of memory leak problems, the standard Go compiler will ensure that taking the address of the final field in a non-zero-sized struct will never return an address which is beyond the allocated memory block for the struct. The standard Go compiler implements this by padding some bytes after the final zero-sized field when needed.
</div>
<p></p>
<div class="tmd-usual">
If the types of all fields in a struct type are zero-sized (so the struct is also a zero-sized type), then there is no need to pad bytes in the struct, for the standard Go compiler treats zero-sized memory blocks specially.
</div>
<p></p>
<div class="tmd-usual">
An example:
</div>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

import (
	"unsafe"
	"fmt"
)

func main() {
	type T1 struct {
		a struct{}
		x int64
	}
	fmt.Println(unsafe.Sizeof(T1{})) // 8

	type T2 struct {
		x int64
		a struct{}
	}
	fmt.Println(unsafe.Sizeof(T2{})) // 16
}
</code></pre>
<p></p>
<div class="tmd-usual">
Also see <a href="https://go.dev/doc/faq#zero_size_types">this official FAQ item</a>.
</div>
<p></p>
<p></p>
<h3 id="new-function" class="tmd-header-3">
Is <code class="tmd-code-span">new(T)</code> a sugar of <code class="tmd-code-span">var t T; (&amp;t)</code>?
</h3>
<p></p>
<div class="tmd-usual">
Generally we can think so, though there may be some subtle differences between the two, depending on compiler implementations. The memory block allocated by <code class="tmd-code-span">new</code> may be either on stack or on heap.
</div>
<p></p>
<h3 id="fatal-error-deadlock" class="tmd-header-3">
What does the runtime error message <code class="tmd-code-span">all goroutines are asleep - deadlock</code> mean?
</h3>
<p></p>
<div class="tmd-usual">
The word <span class="tmd-bold"><span class="tmd-italic">asleep</span></span> is not accurate here, it means <span class="tmd-bold"><span class="tmd-italic">in blocking state</span></span> in fact.
</div>
<p></p>
<div class="tmd-usual">
As a blocking goroutine can only be unblocked by another goroutine, if all goroutines in a program enter blocking state, then all of they will stay in blocking state for ever. This means the program is deadlocked. A normal running program is never expected to be deadlocked, so the standard Go runtime makes the program crash and exit.
</div>
<p></p>
<h3 id="_64-bit-alignment" class="tmd-header-3">
Are 64-bit integer values guaranteed to be 64-bit aligned so that they can be accessed atomically?
</h3>
<p></p>
<div class="tmd-usual">
The addresses passed to the 64-bit functions in <code class="tmd-code-span">sync/atomic</code> package must be 64-bit aligned, otherwise, calls to these functions may panic at run time.
</div>
<p></p>
<div class="tmd-usual">
For the standard Go compiler and gccgo compiler, on 64-bit architectures, 64-bit integers are guaranteed to be 64-bit aligned. So they can be always accessed atomically without any problems.
</div>
<p></p>
<div class="tmd-usual">
On 32-bit architectures, 64-bit integers are only guaranteed to be 32-bit aligned. So accessing many 64-bit integers atomically may cause panics. However, there are some ways to guarantee some 64-bit integers to be relied upon to be 64-bit aligned. Please read <a href="memory-layout.html#64bit-atomic-operation">memory layouts in Go</a> for details.
</div>
<p></p>
<p></p>
<p></p>
<h3 id="atomical-assignment" class="tmd-header-3">
Are assignments of values atomic operations?
</h3>
<p></p>
<div class="tmd-usual">
No for the standard Go compiler, even if the sizes of the assigned values are native words.
</div>
<p></p>
<div class="tmd-usual">
Please read <a href="https://golang.org/doc/faq#What_operations_are_atomic_What_about_mutexes">the official question</a> for more details.
</div>
<p></p>
<p></p>
<h3 id="zero-values-zero-bytes" class="tmd-header-3">
Is every zero value composed of a sequence of zero bytes in memory?
</h3>
<p></p>
<div class="tmd-usual">
For most types, this is true. But we should know that this is compiler dependent. For example, for the standard Go compiler, the statement is wrong for some zero values of string types and float-point types.
</div>
<p></p>
<div class="tmd-usual">
Evidence:
</div>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

import (
	"unsafe"
	"fmt"
)

func main() {
	// case 1:
	var s = "abc"[0:0]
	fmt.Println(s == "") // true
	var addr = unsafe.StringData(s)
	fmt.Println(addr) // &lt;a-non-zero-value&gt;

	// case 2:
	var x = 0.0
	var y = -x
	fmt.Println(y == 0) // true
	var n = *(*uintptr)(unsafe.Pointer(&amp;y))
	fmt.Println(n) // 9223372036854775808
}
</code></pre>
<p></p>
<div class="tmd-usual">
Inversely, for all the architectures the standard Go compiler currently supports, if all bytes in a value are zero, then the value must be a zero value of its type. However, Go specification doesn't guarantee this. I have heard of that on some very old processors, nil pointers are not zero in memory.
</div>
<p></p>
<h3 id="function-inline" class="tmd-header-3">
Does the standard Go compiler support function inlining?
</h3>
<p></p>
<div class="tmd-usual">
Yes, the standard Go compiler supports inlining functions. The compiler will automatically inline some very short functions which satisfy certain requirements. The specific inline requirements may change from version to version.
</div>
<p></p>
<div class="tmd-usual">
Currently (Go Toolchain 1.25), for the standard Go compiler:
</div>
<ul class="tmd-list">
<li class="tmd-list-item">
<div class="tmd-usual">
There are no explicit ways to specify which functions should be inlined in user programs.
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
The <code class="tmd-code-span">-gcflags "-l"</code> build option disables inlining globally, which will prevent all functions from being inline expanded.
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
In user programs, there are not formal ways to prevent inlining of particular functions. You can add a line <code class="tmd-code-span">//go:noinline</code> directive before a function declaration to prevent the function from being inlined, but this way is not guaranteed to always work in the future.
</div>
</li>
</ul>
<p></p>
<h3 id="finalizers" class="tmd-header-3">
Can I use finalizers as object destructors?
</h3>
<p></p>
<div class="tmd-usual">
In Go programs, we can set a finalizer function for an object by using the <code class="tmd-code-span">runtime.SetFinalizer</code> function. Generally, the finalizer function will be called before the object is garbage collected. But finalizers are never intended to be used as destructors of objects. The finalizers set by <code class="tmd-code-span">runtime.SetFinalizer</code> are not guaranteed to run. So you shouldn't rely on finalizers for your program correctness.
</div>
<p></p>
<div class="tmd-usual">
The main intention of finalizers is to allow the maintainers of a library to compensate for problems caused by incorrect library use. For example, if a programmer uses <code class="tmd-code-span">os.Open</code> to open many files but forgets to close them after using them, then the program will hold many file descriptors until the program exits. This is a classic example of resource leak. To avoid the program holding too many file descriptors, the maintainers of the <code class="tmd-code-span">os</code> package will set a finalizer on the every created <code class="tmd-code-span">os.File</code> object. The finalizer will close the file descriptor stored in the <code class="tmd-code-span">os.File</code> object. As mentioned above, the finalizers are not guaranteed to be called. They are just used to make the extent of resource leak as small as possible.
</div>
<p></p>
<div class="tmd-usual">
<span class="tmd-italic">to add best practices and more cases where finalizer doesn't work.</span>
</div>
<p></p>
<div class="tmd-usual">
Please note, some finalizers will never get called for sure, and sometimes setting finalizers improperly will prevent some objects from being garbage collected. Please read the <a href="https://golang.org/pkg/runtime/#SetFinalizer">runtime.SetFinalizer function documentation</a> to get more details.
</div>
<p></p>
<p></p>
<div class="tmd-usual">
<span class="tmd-italic">standard packages</span>
</div>
<p></p>
<h3 id="get-days-of-month" class="tmd-header-3">
How to get the number of days of any month in as few lines as possible?
</h3>
<p></p>
<div class="tmd-usual">
Assume the input year and month are from the Gregorian Calendar (January is 1).
</div>
<pre class="tmd-code disable-line-numbers111">
<code class="language-go">days := time.Date(year, month+1, 0, 0, 0, 0, 0, time.UTC).Day()
</code></pre>
<div class="tmd-usual">
For Go time APIs, the usual month range is <code class="tmd-code-span">[1, 12]</code> and the start day of each month is <code class="tmd-code-span">1</code>. The start time of a month <code class="tmd-code-span">m</code> in year <code class="tmd-code-span">y</code> is <code class="tmd-code-span">time.Date(y, m, 1, 0, 0, 0, 0, time.UTC)</code>. The arguments passed to <code class="tmd-code-span">time.Date</code> can be outside their usual ranges and will be normalized during the conversion. For example, January 32 will be converted to February 1.
</div>
<p></p>
<div class="tmd-usual">
Here are some <code class="tmd-code-span">time.Date</code> use examples in Go:
</div>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

import (
	"time"
	"fmt"
)

func main() {
	// 2017-02-01 00:00:00 +0000 UTC
	fmt.Println(time.Date(2017, 1, 32, 0, 0, 0, 0, time.UTC))

	// 2017-01-31 23:59:59.999999999 +0000 UTC
	fmt.Println(time.Date(2017, 1, 32, 0, 0, 0, -1, time.UTC))

	// 2017-01-31 00:00:00 +0000 UTC
	fmt.Println(time.Date(2017, 2, 0, 0, 0, 0, 0, time.UTC))

	// 2016-12-31 00:00:00 +0000 UTC
	fmt.Println(time.Date(2016, 13, 0, 0, 0, 0, 0, time.UTC))

	// 2017-02-01 00:00:00 +0000 UTC
	fmt.Println(time.Date(2016, 13, 32, 0, 0, 0, 0, time.UTC))
}
</code></pre>
<p></p>
<h3 id="time-sleep-after" class="tmd-header-3">
What is the difference between the function call <code class="tmd-code-span">time.Sleep(d)</code> and the channel receive operation <code class="tmd-code-span">&lt;-time.After(d)</code>?
</h3>
<p></p>
<div class="tmd-usual">
The two will both pause the current goroutine execution for a certain duration. The difference is the function call <code class="tmd-code-span">time.Sleep(d)</code> will let the current goroutine enter sleeping sub-state, but still stay in <a href="control-flows-more.html#states-of-goroutine">running state</a>, whereas, the channel receive operation <code class="tmd-code-span">&lt;-time.After(d)</code> will let the current goroutine enter blocking state.
</div>
<p></p>
<p></p>
<h3 id="trim" class="tmd-header-3">
Calls of the <code class="tmd-code-span">TrimLeft</code> and <code class="tmd-code-span">TrimRight</code> functions in the <code class="tmd-code-span">strings</code> and <code class="tmd-code-span">bytes</code> standard packages often return unexpected results, are there bugs in these function implementations?
</h3>
<p></p>
<div class="tmd-usual">
Aha, maybe there are bugs in the implementations, but none are confirmed now. If the return results are unexpected, it is more possible that your expectations are not correct.
</div>
<p></p>
<div class="tmd-usual">
There are many trim functions in <code class="tmd-code-span">strings</code> and <code class="tmd-code-span">bytes</code> standard packages. These functions can be categorized into two groups:
</div>
<ol class="tmd-list">
<li class="tmd-list-item">
<div class="tmd-usual">
<code class="tmd-code-span">Trim</code>, <code class="tmd-code-span">TrimLeft</code>, <code class="tmd-code-span">TrimRight</code>, <code class="tmd-code-span">TrimSpace</code>, <code class="tmd-code-span">TrimFunc</code>, <code class="tmd-code-span">TrimLeftFunc</code>, <code class="tmd-code-span">TrimRightFunc</code>. These functions will trim all leading or trailing UTF-8-encoded Unicode code points (a.k.a. runes) which satisfy the specified or implied conditions (<code class="tmd-code-span">TrimSpace</code> implies to trim all kinds of white spaces). Each of the leading or trailing runes will be checked until one doesn't satisfy the specified or implied conditions.
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<code class="tmd-code-span">TrimPrefix</code>, <code class="tmd-code-span">TrimSuffix</code>. The two functions will trim the specified prefix or suffix substrings (or subslices) as a whole.
</div>
</li>
</ol>
<p></p>
<div class="tmd-usual">
<a href="https://github.com/golang/go/issues/19172">Some </a> <a href="https://github.com/golang/go/issues/18160">programmers</a> <a href="https://github.com/golang/go/issues/14657">misused</a> <a href="https://github.com/golang/go/issues/19371">the</a> <code class="tmd-code-span">TrimLeft</code> and <code class="tmd-code-span">TrimRight</code> functions as <code class="tmd-code-span">TrimPrefix</code> and <code class="tmd-code-span">TrimSuffix</code> functions when they use the trim functions the first time. Certainly, the return results are very possible not as expected.
</div>
<p></p>
<div class="tmd-usual">
Example:
</div>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

import (
	"fmt"
	"strings"
)

func main() {
	var s = "abaay森z众xbbab"
	o := fmt.Println
	o(strings.TrimPrefix(s, "ab")) // aay森z众xbbab
	o(strings.TrimSuffix(s, "ab")) // abaay森z众xbb
	o(strings.TrimLeft(s, "ab"))   // y森z众xbbab
	o(strings.TrimRight(s, "ab"))  // abaay森z众x
	o(strings.Trim(s, "ab"))       // y森z众x
	o(strings.TrimFunc(s, func(r rune) bool {
		return r &lt; 128 // trim all ascii chars
	})) // 森z众
}
</code></pre>
<p></p>
<h3 id="fmt-print-println" class="tmd-header-3">
What are the differences between the <code class="tmd-code-span">fmt.Print</code> and <code class="tmd-code-span">fmt.Println</code> functions?
</h3>
<p></p>
<div class="tmd-usual">
The <code class="tmd-code-span">fmt.Println</code> function will always write a space between two adjacent arguments, whereas the <code class="tmd-code-span">fmt.Print</code> function will write a space between two adjacent arguments only if both of (the concrete values of) the two adjacent arguments are not strings.
</div>
<p></p>
<div class="tmd-usual">
Another difference is that <code class="tmd-code-span">fmt.Println</code> will write a newline character in the end, but the <code class="tmd-code-span">fmt.Print</code> function will not.
</div>
<p></p>
<h3 id="log-print-println" class="tmd-header-3">
Is there any difference between the <code class="tmd-code-span">log.Print</code> and <code class="tmd-code-span">log.Println</code> functions?
</h3>
<p></p>
<div class="tmd-usual">
The difference between the <code class="tmd-code-span">log.Print</code> and <code class="tmd-code-span">log.Println</code> functions is the same as the first difference between the <code class="tmd-code-span">fmt.Print</code> and <code class="tmd-code-span">fmt.Println</code> functions described in the last question.
</div>
<p></p>
<div class="tmd-usual">
Both of the two functions will write a newline character in the end.
</div>
<p></p>
<h3 id="fmt-print-synced" class="tmd-header-3">
Are <code class="tmd-code-span">fmt.Print</code>, <code class="tmd-code-span">fmt.Println</code> and <code class="tmd-code-span">fmt.Printf</code> functions synchronized?
</h3>
<p></p>
<div class="tmd-usual">
No, these functions are not synchronized. Please use the corresponding functions in the <code class="tmd-code-span">log</code> standard package instead when synchronizations are needed. You can call <code class="tmd-code-span">log.SetFlags(0)</code> to remove the prefix from each log line.
</div>
<p></p>
<h3 id="print-builtin-fmt-log" class="tmd-header-3">
What are the differences between the built-in <code class="tmd-code-span">print</code>/<code class="tmd-code-span">println</code> functions and the corresponding print functions in the <code class="tmd-code-span">fmt</code> and <code class="tmd-code-span">log</code> standard packages?
</h3>
<p></p>
<div class="tmd-usual">
Besides the difference mentioned in the last question, there are some other differences between the three sets of functions.
</div>
<ol class="tmd-list">
<li class="tmd-list-item">
<div class="tmd-usual">
The built-in <code class="tmd-code-span">print</code>/<code class="tmd-code-span">println</code> functions will write to standard error. The print functions in the <code class="tmd-code-span">fmt</code> standard package will write to standard output. The print functions in the <code class="tmd-code-span">log</code> standard package will write to standard error by default, though this can be changed using the <code class="tmd-code-span">log.SetOutput</code> function.
</div>
<p></p>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
Calls to the built-in <code class="tmd-code-span">print</code>/<code class="tmd-code-span">println</code> functions can't take array and struct arguments.
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
For an argument of a composite type, the built-in <code class="tmd-code-span">print</code>/<code class="tmd-code-span">println</code> functions write the addresses of the underlying value parts of the argument, whereas the print functions in the <code class="tmd-code-span">fmt</code> and <code class="tmd-code-span">log</code> standard packages try to write the value literal of the dynamic values of the interface arguments.
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
Calls to the built-in <code class="tmd-code-span">print</code>/<code class="tmd-code-span">println</code> functions will not make the values referenced by the arguments of the calls escape to heap, whereas the print functions in the <code class="tmd-code-span">fmt</code> and <code class="tmd-code-span">log</code> standard packages will.
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
If an argument has a <code class="tmd-code-span">String() string</code> or <code class="tmd-code-span">Error() string</code> method, the print functions in the <code class="tmd-code-span">fmt</code> and <code class="tmd-code-span">log</code> standard packages will try to call that method when writing the argument, whereas the built-in <code class="tmd-code-span">print</code>/<code class="tmd-code-span">println</code> functions will ignore methods of arguments.
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
The built-in <code class="tmd-code-span">print</code>/<code class="tmd-code-span">println</code> functions are not guaranteed to exist in future Go versions.
</div>
</li>
</ol>
<p></p>
<h3 id="math-crypto-rand" class="tmd-header-3">
What is the difference between the random numbers produced by the <code class="tmd-code-span">math/rand</code> standard package and the <code class="tmd-code-span">crypto/rand</code> standard package?
</h3>
<p></p>
<div class="tmd-usual">
The pseudo random numbers produced by the <code class="tmd-code-span">math/rand</code> standard package are deterministic for a given seed. The produced random numbers are not good for security-sensitive contexts. For cryptographical security purpose, we should use the pseudo random numbers produced by the <code class="tmd-code-span">crypto/rand</code> standard package.
</div>
<p></p>
<h3 id="math-round" class="tmd-header-3">
Why isn't there a <code class="tmd-code-span">math.Round</code> function?
</h3>
<p></p>
<div class="tmd-usual">
There is a <code class="tmd-code-span">math.Round</code> function, but only since Go 1.10. Two new functions, <code class="tmd-code-span">math.Round</code> and <code class="tmd-code-span">math.RoundToEven</code> have been added since Go 1.10.
</div>
<p></p>
<div class="tmd-usual">
Before Go 1.10, much time and effort was spent <a href="https://github.com/golang/go/issues/4594">discussing</a> whether or not the <code class="tmd-code-span">math.Round</code> function should be added to standard package or not. In the end, the proposal was adopted.
</div>
<p></p>
<p></p>
<div class="tmd-usual">
<span class="tmd-italic">type system</span>
</div>
<p></p>
<h3 id="incomparable-types" class="tmd-header-3">
Which types don't support comparisons?
</h3>
<p></p>
<div class="tmd-usual">
Following types don't support comparisons:
</div>
<ul class="tmd-list">
<li class="tmd-list-item">
<div class="tmd-usual">
map
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
slice
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
function
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
struct types containing incomparable fields
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
array types with incomparable element types
</div>
</li>
</ul>
<p></p>
<div class="tmd-usual">
Types which don't support comparisons can't be used as the key type of map types.
</div>
<p></p>
<div class="tmd-usual">
Please note,
</div>
<ul class="tmd-list">
<li class="tmd-list-item">
<div class="tmd-usual">
although map, slice and function types don't support comparisons, their values can be compared to the bare <code class="tmd-code-span">nil</code> identifier.
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
<a href="interface.html#comparison">comparing two interface values</a> with <code class="tmd-code-span">==</code> will panic at run time if the two dynamic types of the two interface values are identical and incomparable.
</div>
</li>
</ul>
<p></p>
<p></p>
<div class="tmd-usual">
On why slice, map and function types don't support comparison, please read <a href="https://golang.org/doc/faq#map_keys">this answer</a> in the official Go FAQ.
</div>
<p></p>
<p></p>
<h3 id="nil-equality" class="tmd-header-3">
Why aren't two <code class="tmd-code-span">nil</code> values equal sometimes?
</h3>
<p></p>
<div class="tmd-usual">
<span class="tmd-italic">(</span><a href="https://golang.org/doc/faq#nil_error"><span class="tmd-italic">The answer</span></a><span class="tmd-italic"> in the official Go FAQ may also answer this question.)</span>
</div>
<p></p>
<p></p>
<div class="tmd-usual">
An interface value can be viewed as a box which is used to encapsulate non-interface values. Only values whose types implement the type of the interface value can be boxed (encapsulated) into the interface value. In Go, there are several kinds of types whose zero values are represented as the predeclared identifier <code class="tmd-code-span">nil</code>. An interface value boxing nothing is a zero interface value, a.k.a, a nil interface value. However an interface value boxing a nil non-interface value doesn't box nothing, so it is not, and doesn't equal to, a nil interface value.
</div>
<p></p>
<div class="tmd-usual">
When comparing a nil interface value and a nil non-interface value (assume they can be compared), the nil non-interface value will be converted to the type of the nil interface value before doing the comparison. The conversion result is an interface value boxing a copy of the non-interface value. The result interface value doesn't box nothing, so it is not, or doesn't equal to, the nil interface value.
</div>
<p></p>
<div class="tmd-usual">
Please read <a href="interface.html">interfaces in Go</a> and <a href="nil.html">nils in Go</a> for detailed explanations.
</div>
<p></p>
<p></p>
<div class="tmd-usual">
For example:
</div>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

import "fmt"

func main() {
	var pi *int = nil
	var pb *bool = nil
	var x interface{} = pi
	var y interface{} = pb
	var z interface{} = nil

	fmt.Println(x == y)   // false
	fmt.Println(x == nil) // false
	fmt.Println(y == nil) // false
	fmt.Println(x == z)   // false
	fmt.Println(y == z)   // false
}
</code></pre>
<p></p>
<h3 id="slice-conversion" class="tmd-header-3">
Why don't type <code class="tmd-code-span">[]T1</code> and <code class="tmd-code-span">[]T2</code> share the same underlying type even if the two different types <code class="tmd-code-span">T1</code> and <code class="tmd-code-span">T2</code> share the same underlying type?
</h3>
<p></p>
<div class="tmd-usual">
<span class="tmd-italic">(It looks the official Go FAQ also added </span><a href="https://golang.org/doc/faq#convert_slice_with_same_underlying_type"><span class="tmd-italic">a similar question</span></a><span class="tmd-italic"> not long ago.)</span>
</div>
<p></p>
<p></p>
<div class="tmd-usual">
In Go, values of a slice type can be converted to another slice type without using <a href="unsafe.html">the <code class="tmd-code-span">unsafe</code> mechanisms</a> only if the two slice types share the same <a href="type-system-overview.html#underlying-type">underlying type</a>. (<a href="value-conversions-assignments-and-comparisons.html">This article</a> lists the full list of value conversion rules.)
</div>
<p></p>
<p></p>
<div class="tmd-usual">
The underlying type of an unnamed composite type is the composite type itself. So even if two different types <code class="tmd-code-span">T1</code> and <code class="tmd-code-span">T2</code> share the same underlying type, type <code class="tmd-code-span">[]T1</code> and <code class="tmd-code-span">[]T2</code> are still different types, so their underlying types are also different, which means values of one of them can't be converted to the other.
</div>
<p></p>
<div class="tmd-usual">
The reasons for the underlying types of <code class="tmd-code-span">[]T1</code> and <code class="tmd-code-span">[]T2</code> are not same are:
</div>
<ul class="tmd-list">
<li class="tmd-list-item">
<div class="tmd-usual">
the request of converting values of <code class="tmd-code-span">[]T1</code> and <code class="tmd-code-span">[]T2</code> to each other is not strong in practice.
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
to make the <a href="type-system-overview.html#underlying-type">underlying type tracing rules</a> simpler.
</div>
</li>
</ul>
<p></p>
<p></p>
<div class="tmd-usual">
The same reasons are also valid for other composite types. For example, type <code class="tmd-code-span">map[T]T1</code> and <code class="tmd-code-span">map[T]T2</code> also don't share the same underlying type even if <code class="tmd-code-span">T1</code> and <code class="tmd-code-span">T2</code> share the same underlying type.
</div>
<p></p>
<div class="tmd-usual">
It is possible that values of type <code class="tmd-code-span">[]T1</code> can be converted to <code class="tmd-code-span">[]T2</code> by using the <code class="tmd-code-span">unsafe</code> mechanisms, but generally this is not recommended:
</div>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

import (
	"fmt"
	"unsafe"
)

func main() {
	type MyInt int

	var a = []int{7, 8, 9}
	var b = *(*[]MyInt)(unsafe.Pointer(&amp;a))
	b[0]= 123
	fmt.Println(a) // [123 8 9]
	fmt.Println(b) // [123 8 9]
	fmt.Printf("%T \n", a) // []int
	fmt.Printf("%T \n", b) // []main.MyInt
}
</code></pre>
<p></p>
<h3 id="unaddressable-values" class="tmd-header-3">
Which values can and which values can't have their addresses taken?
</h3>
<p></p>
<div class="tmd-usual">
We can't take the address of the following values:
</div>
<ul class="tmd-list">
<li class="tmd-list-item">
<div class="tmd-usual">
bytes in strings
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
map elements
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
dynamic values of interface values (exposed by type assertions)
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
constant values (including named constants and literals)
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
package level functions
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
methods (used as function values)
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
intermediate values
</div>
<ul class="tmd-list">
<li class="tmd-list-item">
<div class="tmd-usual">
function calls
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
explicit value conversions
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
all sorts of operations, excluding pointer dereference operations, but including:
</div>
<ul class="tmd-list">
<li class="tmd-list-item">
<div class="tmd-usual">
channel receive operations
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
sub-string operations
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
sub-slice operations
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
addition, subtraction, multiplication, and division, etc.
</div>
</li>
</ul>
</li>
</ul>
</li>
</ul>
<p></p>
<div class="tmd-base alert alert-success">
<div class="tmd-usual">
Please note, there is a syntax sugar, <code class="tmd-code-span">&amp;T{}</code>, in Go. It is a short form of <code class="tmd-code-span">tmp := T{}; (&amp;tmp)</code>. However, though <code class="tmd-code-span">&amp;T{}</code> is legal, the literal <code class="tmd-code-span">T{}</code> is still not addressable.
</div>
</div>
<p></p>
<div class="tmd-usual">
Following values can have their addresses taken:
</div>
<ul class="tmd-list">
<li class="tmd-list-item">
<div class="tmd-usual">
variables
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
fields of addressable structs
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
elements of addressable arrays
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
elements of any slices (whether the slices are addressable or not)
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
pointer dereference operations
</div>
</li>
</ul>
<p></p>
<h3 id="map-elements-are-unaddressable" class="tmd-header-3">
Why are map elements unaddressable?
</h3>
<p></p>
<div class="tmd-usual">
The first reason is that it would conflict with maps' internal memory management process. In Go, a map is designed as a container which can contain an unlimited number of entries if memory is available. To ensure good map element indexing efficiency, in the official Go runtime implementation each map value only maintains one continuous memory segment for the entirety of entries stored in that map. Therefore, Go runtime needs to allocate larger memory segments for a map from time to time when more and more entries are being put into the map. In the process, the entries stored on older memory segments will be moved to newer memory segments. There might be also some other reasons causing memory movements of entries. In other words, the addresses of map elements will change from time to time on need. If map elements are allowed to have their addresses taken, then when some map entries are moved, Go runtime would have to update all pointers which are storing the addresses of the moved elements, which brings many difficulties in implementing Go compilers and runtimes and greatly decreases execution performance. So, currently, map elements cannot have their addresses taken.
</div>
<p></p>
<div class="tmd-usual">
Secondly, the map index expression <code class="tmd-code-span">aMap[key]</code> might return an element stored in map <code class="tmd-code-span">aMap</code> or not, which means <code class="tmd-code-span">aMap[key]</code> might still result in a zero value after <code class="tmd-code-span">(&amp;aMap[key]).Modify()</code> is called. This would confuse many people. (Here <code class="tmd-code-span">Modify()</code> refers to a hypothetical method  which would modify the value <code class="tmd-code-span">aMap[key]</code>).
</div>
<p></p>
<h3 id="slice-elements-always-addressable" class="tmd-header-3">
Why elements of a non-nil slice are always addressable, even if the slice is unaddressable?
</h3>
<p></p>
<div class="tmd-usual">
The internal type for slices is a struct like
</div>
<pre class="tmd-code line-numbers">
<code class="language-go">struct {
	// elements references an element sequence.
	elements unsafe.Pointer
	length   int
	capacity int
}
</code></pre>
<div class="tmd-usual">
Each slice indirectly references an underlying element sequence internally. Although a non-nil slice is not addressable, its internal element sequence is always allocated somewhere and must be addressable. Taking addresses of elements of a slice is taking the addresses of elements of the internal element sequence actually. This is why elements of unaddressable non-nil slices are always addressable.
</div>
<p></p>
<p></p>
<h3 id="method-set-relation" class="tmd-header-3">
For any non-pointer non-interface type <code class="tmd-code-span">T</code>, why is the method set of <code class="tmd-code-span">*T</code> always a super set of the method set of <code class="tmd-code-span">T</code>, but not vice versa?
</h3>
<p></p>
<div class="tmd-usual">
Both of these situations involve sugaring, but only one is an intrinsic rule.
</div>
<p></p>
<ul class="tmd-list">
<li class="tmd-list-item">
<div class="tmd-usual">
A value of type <code class="tmd-code-span">T</code> can call methods of type <code class="tmd-code-span">*T</code>, but only if the value of <code class="tmd-code-span">T</code> is addressable. Compilers will take the address of the <code class="tmd-code-span">T</code> value automatically before calling the pointer receiver methods. Because type <code class="tmd-code-span">T</code> can have values that are not addressable, not all values of type <code class="tmd-code-span">T</code> are capable of calling methods of type <code class="tmd-code-span">*T</code>.
</div>
<p />
<div class="tmd-usual">
<span class="tmd-bold">This convenience is just a sugar, not an intrinsic rule.</span>
</div>
<p></p>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
A value of type <code class="tmd-code-span">*T</code>  can always call methods of type <code class="tmd-code-span">T</code>. This is because it is always legal to dereference a pointer value.
</div>
<p />
<div class="tmd-usual">
<span class="tmd-bold">This convenience is not only a sugar, but also an intrinsic rule.</span>
</div>
</li>
</ul>
<p></p>
<div class="tmd-usual">
So, it makes sense that the method set of <code class="tmd-code-span">*T</code> is always a super set of the method set of <code class="tmd-code-span">T</code>, but not vice versa.
</div>
<p></p>
<div class="tmd-usual">
In fact, you can think that, for every method declared on type <code class="tmd-code-span">T</code>, an implicit method with the same name and the same signature is automatically declared on type <code class="tmd-code-span">*T</code>. Please read <a href="method.html#implicit-pointer-methods">methods</a> for details.
</div>
<p></p>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">func (t T) MethodX(v0 ParamType0, ...) (ResultType0, ...) {
	...
}

// An implicit method of *T is automatically defined as
func (pt *T) MethodX(v0 ParamType0, ...) (ResultType0, ...) {
	return (*pt).MethodX(v0, ...)
}
</code></pre>
<p></p>
<p></p>
<div class="tmd-usual">
Please read <a href="https://golang.org/doc/faq#different_method_sets">this answer</a> in the official Go FAQ to get more explanations.
</div>
<p></p>
<p></p>
<h3 id="types-can-have-methods" class="tmd-header-3">
Which types can we implement methods for?
</h3>
<p></p>
<div class="tmd-usual">
Please read <a href="method.html">methods in Go</a> for details.
</div>
<p></p>
<p></p>
<h3 id="declare-immutables" class="tmd-header-3">
How to declare immutable values in Go?
</h3>
<p></p>
<div class="tmd-usual">
There are three <span class="tmd-bold"><span class="tmd-italic">immutable value</span></span> definitions:
</div>
<ol class="tmd-list">
<li class="tmd-list-item">
<div class="tmd-usual">
the values which have no addresses (so they are not addressable).
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
the values which have addresses but are not addressable (their addresses are not allowed to be taken in syntax).
</div>
</li>
<li class="tmd-list-item">
<div class="tmd-usual">
the values which are addressable but their values are not allowed to be modified in syntax.
</div>
</li>
</ol>
<p></p>
<div class="tmd-usual">
In Go, up to now (Go 1.25), there are no values satisfy the third definition. In other words, the third definition is not supported. However, variables of zero-size types may be viewed de facto immutable (addressable) values.
</div>
<p></p>
<div class="tmd-usual">
Name constant values satisfy the first definition.
</div>
<p></p>
<div class="tmd-usual">
Methods and package-level functions can also viewed as declared immutable values. They satisfy the second definition. String elements (bytes) and map entry elements also satisfy the second definition.
</div>
<p></p>
<div class="tmd-usual">
There are no ways to declare other custom immutable named values in Go.
</div>
<p></p>
<h3 id="set-container-type" class="tmd-header-3">
Why isn't there a built-in <code class="tmd-code-span">set</code> container type?
</h3>
<p></p>
<div class="tmd-usual">
Sets are just maps but don't care about element values. In Go, <code class="tmd-code-span">map[Tkey]struct{}</code> is often used as a set type.
</div>
<p></p>
<h3 id="byte-rune-slice-string" class="tmd-header-3">
What is byte? What is rune? How to convert <code class="tmd-code-span">[]byte</code> and <code class="tmd-code-span">[]rune</code> values to strings?
</h3>
<p></p>
<div class="tmd-usual">
In Go, <code class="tmd-code-span">byte</code> is an alias of type <code class="tmd-code-span">uint8</code>. In other words, <code class="tmd-code-span">byte</code> and <code class="tmd-code-span">uint8</code> are the same identical type. The same relation is for <code class="tmd-code-span">rune</code> and <code class="tmd-code-span">int32</code>.
</div>
<p></p>
<div class="tmd-usual">
A <code class="tmd-code-span">rune</code> often is used to store a Unicode code point.
</div>
<p></p>
<div class="tmd-usual">
<code class="tmd-code-span">[]byte</code> and <code class="tmd-code-span">[]rune</code> values can be explicitly and directly converted to strings, and vice versa.
</div>
<p></p>
<pre class="tmd-code line-numbers">
<code class="language-go">package main

import "fmt"

func main() {
	var s0 = "Go"

	var bs = []byte(s0)
	var s1 = string(bs)

	var rs = []rune(s0)
	var s2 = string(rs)

	fmt.Println(s0 == s1) // true
	fmt.Println(s0 == s2) // true
}
</code></pre>
<p></p>
<div class="tmd-usual">
About more on strings, please read <a href="string.html">strings in Go</a>.
</div>
<p></p>
<p></p>
<h3 id="pointer-atomic" class="tmd-header-3">
How to manipulate pointer values atomically?
</h3>
<p></p>
<div class="tmd-usual">
Please read <a href="concurrent-atomic-operation.html#pointer">atomic operations for pointers</a>.
</div>
<p></p>
<p></p>
<div class="tmd-usual">
<span class="tmd-italic">others</span>
</div>
<p></p>
<h3 id="about-iota" class="tmd-header-3">
What does <code class="tmd-code-span">iota</code> mean?
</h3>
<p></p>
<div class="tmd-usual">
Iota is the ninth letter of the Greek alphabet. In Go, <code class="tmd-code-span">iota</code> is used in constant declarations. In each constant declaration group, its value is <code class="tmd-code-span">N</code> in the <span class="tmd-bold"><span class="tmd-italic">N</span></span>th constant specification in that constant declaration group. This allows for easy <a href="https://golang.org/ref/spec#Iota">declaration of related constants</a>.
</div>
<p></p>
<p></p>
<h3 id="check-if-channels-closed" class="tmd-header-3">
Why isn't there a built-in <code class="tmd-code-span">closed</code> function to check whether or not a channel is closed?
</h3>
<p></p>
<div class="tmd-usual">
The reason is that the usefulness of such function would be very limited, while the potential for misuse is high. The return result of a call to such function may be not able to reflect the latest status of the input channel argument. So, it is not a good idea to make decisions relying on the return result.
</div>
<p></p>
<div class="tmd-usual">
If you do need such a function, it would be effortless to write one by yourself. Please read <a href="channel-closing.html">this article</a> to get how to write <code class="tmd-code-span">closed</code> functions and how to avoid using such a function.
</div>
<p></p>
<p></p>
<h3 id="return-local-pointers" class="tmd-header-3">
Is it safe for a function to return pointers of local variables?
</h3>
<p></p>
<div class="tmd-usual">
Yes, it is absolutely safe in Go.
</div>
<p></p>
<div class="tmd-usual">
Go compilers which support stack will do escape analysis. For the standard Go compiler, if the escape analyzer thinks a memory block will only be used in the current goroutine for sure, it will allocate the memory block on stack. If not, the memory block will be allocated on the heap. Please read <a href="memory-block.html">memory block</a> for more information.
</div>
<p></p>
<p></p>
<h3 id="gopher" class="tmd-header-3">
What does the word <span class="tmd-bold"><span class="tmd-italic">gopher</span></span> mean in Go community?
</h3>
<p></p>
<div class="tmd-usual">
In the Go community, a <span class="tmd-bold"><span class="tmd-italic">gopher</span></span> means a Go programmer. This nickname may originate from the fact that Go language adopted <a href="https://blog.golang.org/gopher">a cartoon gopher</a> as the mascot. BTW, the cartoon gopher is designed by <span class="tmd-italic">Renee French</span>, who is the wife of the (first) Go project leader, <span class="tmd-italic">Rob Pike</span>.
</div>
<p></p>
<p></p>
</div>
<p></p>
</div>
